guest-agent: fix v1 leftovers and pin the two untested v1 methods - #1118

… 400

The doc comment on the frozen `Verify` makes an observable claim: k256 rejects
high-S inside the verification rather than in `from_slice`, so a malleated
signature comes back as HTTP 200 with `valid: false`, not as the 400 a parse
failure would produce. Nothing pinned it.

The test builds the malleation by negating `s`, then checks it is the real
thing before using it -- `normalize_s` is `Some` only for a high-S signature,
and it must normalise back to exactly the signature that just verified -- so
the assertions cannot pass against a no-op. Both halves of the claim are
asserted: `.expect()` for the status code a 0.5.x client branches on, `!valid`
for the security answer.

A k256 upgrade that moved the check into parsing would keep the second and
silently break the first. That is the drift the comment warns about.

Three edits from review of the preceding two commits.

`GetAttestationForAppKey`'s comment said the report data was "the same
commitment the frozen `Sign` path's key uses". `Sign` uses a key, not a
commitment. Say what is actually shared: the derivation -- same path, purpose
and base algorithm -- so the attested public key is the one that signs.

The Errors table now lists a row that no client can clear by changing its
request. Since a 400 in this API means "the method ran and failed" rather than
"your request was malformed", say so where the table says everything above is
a 400, and say that the message in the body is what separates the two.

`app-health-checks.md` restated the fail-open mechanism the proto comment and
the spec already carry. Keep the reading an operator needs -- what `true` means
for an app that opted out -- and drop the third copy of how it is computed.
Also reflow the paragraph the `ra-tls` pointer fix left short of the fill.

… GPU

`AttestGpu` reported "GPU attestation is not available in this image" as an
uncoded error, which `dispatch_prpc` turns into the generic 400. That tells a
client its request was malformed. It was not: the request is well-formed, and
no other request would succeed either, because the image ships no nvattest and
will not grow one at runtime. A client branching on the status retries with
different arguments forever instead of falling back.

`ra_rpc::ErrorExt::with_code` already carries a chosen status through the
transport, and `code_of` walks the whole error chain, so the code survives the
handler's `.context("GPU attestation failed")`. 501 rather than 503 because the
capability is absent for the lifetime of the CVM, not temporarily unavailable.

A malformed nonce keeps the default 400 -- that one really is the caller's
fault, and the two failures must not be indistinguishable.

Safe to change now: `AttestGpu` is v1-only and never shipped in a release, so
no deployed client is reading the old 400. `rpc_service_v1.rs` already asserts
it is absent from both frozen surfaces.

The availability probe moves from `nvattest::available()` to a `GpuAttestor`
field holding the binary's path. Without that, a test for the unavailable
answer would pass only on a host with no nvattest installed and would spawn a
real collection against the host's GPUs anywhere else. The test fixture pins it
to a path that cannot exist, so every guest-agent test sees the same answer.

Documented in the proto comment, the spec's Errors and Status codes sections,
and the curl API reference, which listed only 400 and 500.

`return Err(anyhow!("...").with_code(501))` is four moving parts to say one
thing, and it reads as an error construction rather than as a control-flow
exit -- the two existing sites both wrote it differently, one importing
`ErrorExt` and one calling it as a free function.

`ra_rpc::bail!(501, "...")` expands to exactly that expression. The format
arguments are forwarded to `anyhow::anyhow!` verbatim, so nothing new has to be
learned, and the macro resolves `anyhow` through a hidden re-export so a caller
does not need it in scope.

The code is the first argument and is mandatory. An error with no status to
choose should keep using `anyhow::bail!` and be reported as CODE_BAD_REQUEST,
which is the correct default; requiring the code here means the two spellings
say which kind of failure they are. `gpu_attest.rs` now shows both in one
function -- a bad nonce bails plainly, a missing nvattest bails with 501.

Converted both existing sites. The 413 path in `read_data` is already covered
end to end by `status_codes::a_payload_over_the_limit_is_rejected`, so the
macro reaching the transport is pinned without a new test; the unit test added
here covers the part that test cannot see, that the code survives the
`.context(..)` a handler adds on the way out.